In a transaction processing system, the system is capable of managing various tasks, including transaction routing, such as telephone call routing, e-mail routing, web request routing, etc. A typical transaction processing system is equipped to receive transaction requests, or events (e.g., calls, e-mails, network requests, etc.) over a variety of media, and to process and facilitate transactions between the source of the event and an agent responsive to such a request.
For each type of event for which the transaction processing system is equipped to respond, one or more administrative clients is configured with workflow definitions that define workflows that are executed by one or more workflow server engines. In this way, when a pre-defined event is received by the transaction processing system, the transaction processing system executes a workflow which has been previously configured.
One problem with prior art transaction processing systems relates to the difficulty in handling new types of events. When a transaction processing system is set up, it is capable of handling various types of events and executing workflows in response to the events. However, if the user of the transaction processing system wants to add another type of event and have the transaction processing system respond to the new type of event by executing a workflow, the core workflow server engine must be recompiled. As a result, the transaction processing system is inflexible and can not be customized very easily. It would be desirable to provide a transaction processing system which is extensible so that new kinds of events can be handled without changing the core workflow execution method.